STraTOS 1997 April & May/STraTOS 1 - 1997 April & May.iso/CD01/INTERNET/SITES/RAND/ALL95.LZH/letters_tj/text0019.txt

Text File | 1995-10-04 | 10.2 KB | 193 lines

Hi,

>I think a two word title would be better, but for the time being it's not
>bad at all.
OK OK. BAD MOOD.

>He's back now, by the way. I exchanged some email with him today.
Yes, I did,too. And the phone should ring in a minute or two, in fact.

>I think we should set up some kind of mailing list to make the discussions
>easier, especially if more people get involved. You don't happen to know
>anything about how to do that, do you?
Well, I think there are some standard programs to manage this. The problem
would be to get a specific email address for it, cause here we depend on a
common RS6000 and don't have our own site. So we need authorizations.
I think you already have a few email addresses. Could you get one more for
the list? There should be a unix account with it, so we can set up the
program that will manage the list. I could look for the programs, if you
want me to.

>Anything special you could recommend? I'm out of books at the moment.
Yes, if you've never read it, try John Fante. Really very great realistic stuff.
Also, I like Boris Vian a lot, but I don't know what it looks like once
translated: it relies so much on the style and the language.
Try Alexandre Dumas' Count of Monte Cristo. Great adventure stuff. The kind
of books you're supposed to read when you're 14. But I still like it a lot.
Then, there is Stefan Sweig's twenty four hours in the life of a woman.
Celine's travel to the end of the night (these are all approximative
translations of the titles in french...)
I'm giving you title of some of the books I read recently. I'll take a look
in my library and make you a top twenty or something like that.
You see, all this is very classical stuff. But I had never read them, and it
was a pity.

>Well, so far I have no plans on quitting so hopefully I'll be pretty good
>in 17 years or so...   ;-)
It's a very exciting sport. I like this kind of very polite, but intense
fight. And you're supposed to speak french when fencing. Official language.

>> often play with the idea of digging my old sword out of the attic.
>What type of weapon did you use? Foil?
I don't know how it's called in english. I did the "fleuret" in the
beginning. Very precise stuff. Then I switched to "sabre" (the weapon with
which you touch with the edge). This weapon is a lot more savage and
aggressive. Never really tried the third one ("epee"). The way you can touch
any part of the body seemed very confusing to me.

>I can't find any literature that mentions much about anything other than
>that, but I'm learning epee (Really strange name that. In Swedish we
>use the same word as for rapier), which needs quite another type of
>tactics it seems.
Yes, the epee is really something different. And when you watch the fights,
it seems like you couldn't say who won. It's like a gun fight in westerns.
The opponents observe each other, and then, in one second, it's over.

>Take a look at how the drawing occurs in 'F'/'W' mode with single step.
>The image is built up in a very strange way, but nothing is drawn twice
>(I even XOR everything to show that absolutely clear) except for the
>strange special cases I've mentioned.
I have no clue yet, but will try to understand this. I have to get a doom 1
wad home to use it on the falcon. I only have doom 2 here. BTW, would it be
very difficult to make dview work with doom 2 wads?

>Consider the problem of drawing a sprite behind a low pillar some way 'into'
>the picture:
>- It's more or less impossible to draw the sprite before or
>  during the drawing of floors, ceilings and walls since there would have to
>  be a lot of masking etc going on.
>- The legs of the monster are covered by both the walls and the top surface
>  of the low pillar.
>Now, without having all the coordinates for the pixels that constitue our
>pillar, we can't help drawing the monster partly on top of it, which
>needless to say would look _bad_.
>Of course different parts of the monster could be covered by different
>pillars and 'stalagtites' as well as walls from the sides...
OK. This is what I thought: as you're drawing (well, I believe) the ssectors
more or less front to back, and walls in doom have just three parts, the
transparent one being the middle one (correct?), couldn't you keep track,
for each column in the screen, of the highest pixel drawn from the bottom
and of the lowest from the top? I mean, all the walls and sprites contained
in sectors not yet drawn will be clipped by these values (a completely drawn
column having top and bottom joining each other).
I'll try to be clearer: You draw (clipped) the current ssector. If there are
transparent segments, you recurse to the corresponding ssectors. When this
is done, you draw the sprites contained in the ssector (clipped by our
column table). Then, and only then, you update the column table (which means
you have to keep a local table for the currents ssector, I believe).
Does this seems feasible to you?
Ah, but I've just thought about something... The problem is that you'd have
to stack column tables because of the sprites which have to be drawn back to
front.
I have to think a little more about it. Perhaps there's a way, still.
I don't know. Perhaps all this is just crap. I have to understand Dview
better, first, I believe.
Perhaps it could be managed by keeping a permanent and global column table,
updated each time you draw an opaque segment. And when you recurse to a new
ssector, you just give it the coordinates of the quadrilateral polygon that
must clip it. With both the clipping polygon and the column table, there
should be no problem, even with the sprites. Of course, some sprites would
be drawn in several parts.
Is this clear? Any question?
Does this seem efficient to you?
Of course, this is perhaps stupid, because it is theory.

>Ah, this really is difficult. Without bothering about the sprites we could
>probably make the engine quite a bit faster, but putting them in afterwards
>_could_ be _very_ difficult. As I've mentioned elsewhere, I think we'd
>need all the pixel coordinate info to do the sprites right as well...
Impractical. There must be a "right moment" to draw the sprites without
bothering about all this.

>> draw. And do the transparent textures bring problems?
>I've not really considered those yet. Are they really that common in DOOM?
Not exactly common, but they definitely exist. In fact, in the first level
of doom 2, there is a semi-transparent door (I mean, you can see through
some parts) and you can shoot through it (there is a monster behind and he
shoots too). Anyway, these textures should be drawn after the return of the
recursion drawing of the ssector behind it. So in this case, some parts of
the screen will be drawn twice (as in the case of sprites). I would be
curious to know how doom handles this. But they should be no problem.
Anyway, they are always associated with a transparent sector, so this should
work.

>There are none in Jaguar DOOM and it doesn't seem to matter much, but then
>those levels have been redesigned, which obviously is not an option for us.
Exactly. And if we want it to work with doom2, we can't escape these.

>> Yes, I thought the right way to do it was to draw all the solid walls of a
>> ssector, and then, for each transparent wall, to look in the BSP which
>> ssector is behind it, and draw this sector, clipped by the transparent wall.
>You wouldn't really have to consider the transparent wall at while drawing
>what is behind it, I think. Just draw it on top afterwards.
What I meant was, clipped by the boundaries of the segment. Not by each
transparent part of it. So, right, you draw it on top afterwards.

>without every drawing a pixel twice. So the order (front to back or the
>reverse) of the drawing is actually unimportant.
Yes it seems to be important when you have to draw sprites or transparent
textures, because then you have to draw some pixels twice. Well, I think.

>_But_, you would need to keep all the coordinate information I optimized
>away if you were going to remember what wall etc you should draw on top.
>Doing it only for transparent walls might be workable if they really are
>as uncommon as I believe.
What I call a transparent wall can be the boundary between two ssectors, not
always corrseponding to a transparent texture or even to a real wall. So
they are very common.

>By the way, I'm not sure what definitions you use for 'tranparent' and
>'semi-transparent' walls. That might be a communication problem.
>What I mean (and I only use one of the terms) is a wall that has a texture
>with transparent holes in it. Most windows etc only have walls at the top
>bottom and thus don't need any kind of transparency. Diagonal windows and
>cell bars that are in some places do, however.
Yes, so we didn't speak about the same thing.

It really seems like the algorithm has to be strongly restrained by the fact
that there will be sprites.

>No, you've got to draw a bunch of horizontal lines which is much easier.
>It would even be enough to clear the screen before you start drawin, but
>that might be slower.
Yes it will. But in dview, don't you do this already (if you xor, you must
have cleared before?)

>It's those display glitches that I can't get rid of. I've been _sure_ so
>many times now that I've got rid of them, only to find out that my new
>'fixed' code don't improve things at all or causes major havoc all over
>the place...
Just wait a little, sleep well, and one morning, you'll have the answer.
It's true that sometimes, to get an answer, you have to stop thinking about
the problem.

>Ooops, I just got a warning that the system is going down in a couple of
>minutes so I guess I should send this off. I've not reread it very
>carefully, but I hope it's more or less coherent.
Yes. Don't worry about this.

Regards,
Bertrand
+-----------------------------------------------------------+
|Bertrand Le Roy      |A Darwinian theory of Gravitation:   |
|[e-mail]|In the beginning,  mature apples fell|
|tel. [phone]     |in all directions. But only the trees|
|fax. [phone]     |whose apples fell down have survived.|
+-----------------------------------------------------------+
|Laboratoire de Gravitation et Cosmologie Relativistes      |
|Universite Pierre et Marie Curie, tour 22-12, 4e etage     |
|4, place Jussieu, 75252 Paris Cedex 05                     |
+-----------------------------------------------------------+